TIPOS DE RIESGO DENTRO DE DESAROLLO DE SOFTWARE

1. Riesgo del proyecto: Amenazan el plan y calendario. Ej. Enfermedad de un programador.
2. Riesgos técnicos: Amenazan la calidad y actualidad del software. Ej. Win 8, riesgos de compatibilidad.
3. Riesgos empresariales: Amenazan la viabilidad del riesgo.
• Puedo construir un software muy bueno pero no que luego no me lo quieran comprar. Ej. METSI propuesta de Exactas para Garbarino.
• Puedo construir un software muy bueno pero que ventas no destaque las funcionalidades adicionales que el mismo proporciona, no lo sepa vender.
• Puedo perder apoyo presupuestario por defectos y políticas.
• Construir un software que ya no puede ser comercializado por la empresa.

CATEGORÍAS DEL RIESGO (tomado de fuerza aérea estadounidense, aplicable para la materia).

1. Riesgos del rendimiento: que no cumpla la satisfacción de requisitos.
2. Riesgos de costos: Amenazan al proyecto.
3. Riesgos de apoyo (soporte): Amenazan las correcciones, los cambios y mejoras.
4. Riesgos de calendario (de plazo). Riesgo de que la empresa se vaya, quiebre o no haya actualizaciones.

Tabla de riesgos:

Se debe confeccionar una tabla de riesgos que contempla todos los potenciales riesgos del proyecto a los que luego se les asignará una determinada probabilidad de ocurrencia, y el impacto que las mismas generarían en el proyecto en caso de darse, a los efectos de mantenerlos controlados.

Proyección de los riesgos:

1. Probabilidad de que el riesgo ocurra.
2. Consecuencias asociadas al riesgo.
3. Estimar el impacto y el producto (puede tener alta probabilidad y bajo impacto). Voy viendo qué riesgo tiene mayor peso o importancia en el proyecto.
4. Valorar la precisión global.

MATRIZ DE RIESGOS:

Matriz en la cual se colocan todos los potenciales riesgos ubicados en ella según su probabilidad de ocurrencia y según el impacto que generen en el proyecto.

Viéndolo como un gráfico de coordenadas cartesianas, el eje de las x representaría el impacto y el eje de las y la probabilidad de ocurrencia del mismo.

Es posible trazar una línea transversal que divide en dos a dicha matriz, por debajo de la cual los proyectos deberán controlarse, ya sea bajar su probabilidad de ocurrencia o reducir su impacto, dado que la ocurrencia de dichos riesgos en el proyecto pueden llevar al fracaso del mismo.

El tratamiento de los riesgos tiene un costo asociado, por lo tanto no se pueden considerar todos los riesgos. Por ejemplo, la AFIP no se ocupó de los terremotos, dado su baja probabilidad de ocurrencia en el país y el alto costo que ello implicaría.

ESTRATEGIAS PARA EL CONTROL DE COSTOS:

REACTIVAS:

Son estrategias que tienen por objetivo atacar al riesgo en caso de que ocurra (reaccionar frente al hecho consumado). Ej: Bomberos.

Tengo que contar con la fuerza suficiente para que esto funcione.

PROACTIVAS:

Ej: Póliza de seguro. Trato de prevenir en caso de que el riesgo ocurra.

No hay una mejor estrategia sino que dependen del tipo de riesgo. Hay riesgos que hay que esperar que ocurran para atacar, no se pueden prevenir. Y el hecho de atacarlos cuando ocurren es muy costoso. Si bien ambas son necesarias, la proactiva lo es más “mejor prevenir que curar”.

Ej: incendio.

Entonces se arma un plan MMR (Mitigación, Monitoreo y Manejo del Riesgo) el cual contempla qué se debe hacer para minimizar la probabilidad de ocurrencia y el impacto de los mismos.

Si identifican, controlan, minimizan o eliminan los riesgos a un costo aceptable. Dicho proceso es cíclico y debe llevarse a cabo en forma periódica.

Monitorización: Lo voy midiendo cada tanto.

Se arma una “Hoja de información del Riesgo”

Plan de contingencias:

Instrumento de gestión para el buen gobierno de las tecnologías de la información y las comunicaciones, que contienen medidas técnicas, humanas, organizativas necesarias para garantizar la continuidad del negocio y las operaciones de una compañía ante una situación de peligro concreto.

Ejemplo: Incendio que ocasiona la destrucción de tecnologías o el acceso a las mismas (ejemplo destrucción total de una escalera que impide el acceso a las mismas).

Solución: Plan de contingencias que involucra el acceso remoto desde otro lugar para continuar la operatoria de la empresa.

ONTI=> Los organismos nacionales deben cumplir con una determinada política de seguridad de la información.

Decisión administrativa N° 669/2004 y por resolución SGP N° 45/2005.

AGENDA

-Consideración previa

-Gestión de Configuración

-Mantenimiento

-Reingeniería

-Reutilización

CMMR

MODELO COCOMO

Consideraciones previas:

• Cuando se construye un software ocurren cambios, es inevitable.
• Ocurren en cualquier parte del proceso, no solo al final. Ej. Por nueva normativa, resolución de AFIP o lo que fuera.
• La gestión del cambio se inicia con la gestión del proyecto ocuparnos desde el inicio
• Ocurre un cambio una vez que el software se instaló, y eso es el mantenimiento.

Los cambios pueden originarse por:

• Nuevas condiciones del mercado o negocio.
• Nuevas necesidades del cliente.
• La reorganización, el crecimiento o la reducción del negocio (compramos otra fábrica y ahora hay que incorporarlas).
• Restricciones presupuestarias o de calendarización.

Ej: Nos quedamos sin presupuesto ¿qué hacemos? Nos tenemos que adaptar a lo que pase y ocuparnos. Por ejemplo: La compra de un área nueva.

Concepto de Gestión de la configuración de Wikipedia.

Configuración de un conjunto de procesos destinados a asegurar la validez del producto destinado a asegurar la validez del producto, obtenido durante cada etapa de desarrollo de software de SÍ, a través de una estructura de control de cambios, realizados sobre ellos y de la disponibilidad constante de una versión estable de cada elemento, para toda persona involucrada.

Cambio-> Degradación de software. Estructura de control para asegurarse que en cada momento tengo una versión entregable que funciona a veces pasa que se actualiza una versión pero no existe una documentación, no se distribuye, no se cambia la BD, no se capacita, no tiene manuales, etc. Se deben considerar todas las demás cosas respecto a las actualizaciones.

Si en el medio del proceso hay que volver hacia atrás debo asegurar que exista una versión operativa.

La idea es llevar algún reporte.